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REMARKS 

Applicant wishes to thank the Examiner for discussing this case on June 1 5, 
2006, at which time the new matter rejections and art rejections were discussed in 
preparation for the present RCE. 

Claims 1-23 are pending in the present application. In the final Office Action of 
January 31, 2006, claims 1 and 18 were rejected under 35 U.S.C. §112, first paragraph, 
for including new matter. Additionally, claims 1-3, 8, and 14-19 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Thibault in view of Stawikowski . 
Additionally, claims 4-7, 9-11, and 20-23 were rejected under 35 U.S.C. §103(a) as 
being unpatentable over Thibault in view of Stawikowski in further view of Kastner. 
Finally, claims 12 and 13 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Thibault in view of Stawikowski in further view of Kalaian . 

Rejections under §112, first paragraph 
The Office Action rejected claims 1 and 18 under §112, first paragraph, for 
including new matter. In particular, responsive to the previous Amendment filed in the 
present application, the Office Action rejected claim 1 for the amended additions to the 
claims that called for "an Internet communications program that receives an Internet 
signal having socket API data and formatted in accordance with an Internet transport 
layer protocol and an Internet network layer protocol a TCP/IP protocol " and "wherein 
the network signal is not formatted in accordance with the Internet transport layer 
protocol and an Internet network layer protocol TCP/IP protocol ." Similarly, the Office 
Action rejected claim 18 for calling for "wherein the Internet signals are formatted in 
accordance with an IP protocol Internet type protocol and the network signals are not 
formatted in accordance with the Internet type protocol the IP protocol ." 

With respect to the amendment to claim 1 8, Applicant contends that an 
amendment that changes the term "Internet-type protocol" to "IP protocol" is not new 
matter. At the time the application was filed, one of ordinary skill in the art would 
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understand that the broad phrase "Internet-type protocol" readily encompasses the 
narrower "IP protocol." In support, Applicant cites pages 9 and 10 of the Specification, 
which provide detailed explanations of "IP protocols". 

With respect to claim 1, Applicant cites pages 8 through 10 of the Specification 
as teaching the requisite "Internet transport layer protocol" and "Internet network layer 
protocol." As described in the exhibit presented with the original amendment 
(www.protocols.com/pbooks/tcpipl-htm), IP is an Internet "network layer" protocol 
and, TCP and UDP are Internet "transport layer" protocols. FTP and HTTP are 
common "application layer protocols". To this end, pages 4 and 6 as well as pages 8 
through 10 explain each of these "layers". 

For at least these reasons, Applicant believes that the rejections under §112, first 
paragraph, have been overcome. 

Rejections under §103 fa) 

Claims 1-3, 8, and 14-19 were rejected under 35 U.S.C. §103(a) as being 
unpatentable over Thibault in view of Stawikowski . 

Generally the present invention allows industrial control devices to 
communicate with remote Internet users, even though the control devices don't have 
powerful enough computers to handle the full program needed for that communication 
(e.g., the TCP/IP stack). 

In particular, the claimed invention allows control devices to run only the 
application layer of Internet communication protocol (i.e., serve HTTP) and moves the 
transport layer protocol and a network layer protocol (e.g., TCP/IP) to a central Internet 
interface. When Internet data arrives at the industrial controller, the Web access 
interface strips off the HTTP and then forwards the data to the control devices using the 
standard industrial control communication protocol which does not support the Internet 
transport layer and network layer protocol. Again, this operability is described on page 
4 and page 5 of the present application. 
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The Office Action cited Thibault as disclosing an industrial control system 
providing for web access to "control devices'*. However, Thibault teaches that the 
individual "control devices" cannot serve web data because they don't have an 
application layer program. To this end, Stawikowski was cited as teaching the serving 
of web data from control modules and transmitting that web data to the Internet using 
UDP/IP (an Internet transport and network protocol). 

As the claim was originally drafted, it was required that the web data at the 
control devices be transmitted over a control network not supporting TCP/IP. 
Technically Stawikowski in teaching the use of UDP/IP teaches a non-TCP/IP 
communication with control devices. Yet Stawikowski clearly teaches away from the 
intended benefit of the present invention in eliminating the need for the control devices 
that support a complex Internet communication protocol in addition to the protocol of 
the standard control network. 

Accordingly, the Applicant amended claims 1,18 and 21 to indicate that the 
communication with the control devices must not use an Internet transport and network 
layer protocol. This limitation was embodied in elements of claim 1 that call for "an 
Internet communications program that receives an Internet signal having socket API 
data and formatted in accordance with an Internet transport layer protocol and an 
Internet network layer protocol " and "wherein the network signal is not formatted in 
accordance with the Internet transport layer protocol and an Internet network layer 
protocol ." 

Since the device resulting from a combination of Thibault and Stawikowski 
clearly could not provide the intended benefit of the present invention by eliminating 
the overhead of the transport and network layer protocol of TCP/IP or UDP/IP (since 
Stawikowski requires UDP/IP to facilitate communication), Applicant asserted that the 
claimed invention was patentably distinct from the art of record. 

A significant distinction between the present invention and the combination of 
Thibault and Stawikowski is that the latter combination prevents the control devices 
from being self-contained with respect to the data they exchange with a browser on the 
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Internet. Thibault requires the creation and downloading of new objects to the object 
manager 25 as new control devices are added to the control system. The objects are 
necessary to interpret data held in the control devices as application layer data readable 
by a browser. While Thibault recognizes that it is impractical for the control devices to 
hold an entire Internet stack (network, transport and application layers), Thibault does 
not recognize that a portion of the stack (the application layer) could be efficiently held 
in the control devices. Furthermore, Thibault does not recognize that by allowing the 
control devices to hold the application layer, the need to reprogram a central object 
manager for each new object is eliminated. Thibault and Stawikowski fail to teach the 
communication of socket API data (application layer data) from the control devices to a 
web access interface without using an Internet transport layer protocol and an Internet 
network layer protocol. Hence, the claimed invention is a significant improvement over 
the art of record. 

Therefore, claim 1 as a whole, including the subject matter that was apparently 
not considered because it was incorrectly considered new matter, is patentability distinct 
from the art of record. As such, claims 2-17 are in condition for allowance at least 
pursuant to the chain of dependency. 

Regarding claim 18, this claim was amended in a manner similar to that of claim 
1 so as to indicate that the signals received by the "first means" must be formatted in 
accordance with the IP protocol (a network layer protocol) while the signals sent to the 
control device cannot be formatted in accordance with the IP protocol. Accordingly, 
the proposed combination of Thibault and Stawikowski in which TCP/IP is translated 
into UDP/IP would not anticipate these claims since both use IP. Furthermore, the cited 
combination does not contemplate the goal of eliminating the need for network layer 
and transport layer programs in each of the individual devices (because both TCP/IP 
and UDP/IP are network and transport layers) because such would require excess 
memory and processing capability beyond the typical control devices at this time. In 
this regard, Applicant asserts that the combination of Thibault and Stawikowski does 
not teach or suggest that which is called for in claim 18. In fact, Applicant asserts that 


{00102566.DOC /} 


Serial No. 09/964 5 916 

Reply to Office Action of January 31, 2006 

Page 12 of 13 

the proffered combination actually teaches away from the claimed invention by 
proposing a system that does not provide the benefit of the present invention. Hence, 
the proffered combination is improper under MPEP §§2141 .02, 2143, and 2145. 

Regarding claim 21, although unaddressed in the Office Action, the claim calls 
for socket API data to be extracted from the TCP/IP protocol on the Internet and 
retransmitted to the control devices using a control network protocol, for example, 
DeviceNet or ControlNet, as listed in the present application. However, Stawikowski 
teaches retransmission of this data in UDP/IP protocol, which is an Internet protocol 
and not a control network protocol. Accordingly, the proffered combination of Thibault 
and Stawikowski could not be said to suggest that which is called for in claim 21. 

Responsive thereto, the Office Action cited Stawikowski' s explanation of SOAP 
protocols for communication of both configuration and programming. However, 
Stawikowski does not teach or suggest the claimed steps of extracting socket API data 
in the form of a socket API signal determining an appropriate destination control 
device from among the plurality of control devices, formatting the socket API signal in 
accordance with a control network protocol and an internal media access control 
protocol to produce a network signal, and delivering the network signal to the 
appropriate destination control device so that the socket API data can be processed by 
the respective web server program. Rather, as described in Stawikowski , SOAP, a 
general protocol for object access and not a control network protocol like DeviceNet or 
ControlNet, is utilized for a broad sweeping range of communications. Hence, 
Stawikowski cannot be said to teach or suggest the claimed method that includes 
extracting socket API data from the TCP/IP protocol on the Internet and then 
reformatting and retransmitting data to control devices using a control network protocol. 

Therefore, for at least these reasons, claim 21 is patentably distinct from the art 
of record. Accordingly, claims 22 and 23 are in condition for allowance at least 
pursuant to the chain of dependency. 

Additional clarifying claim amendments have been made to indicate better the 
relationship of the elements of the present invention to the control network. 
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Accordingly, Applicant believes the application is in condition for allowance, 
and a Notice of Allowance is requested. However, should the Examiner disagree, the 
Examiner is invited to contact the undersigned at the telephone number appearing below 
if it is believed that such would advance the prosecution of this application. 

Respectfully^libmitted, / 
BRIAN BATKE E3^CL. / 


Keith M. Baxter^R^gfNo. 3J^33 
Boyle Fredrickson NewhfJlm Stein 

& Gratz S.C. 
250 East Wisconsin Avenue 
Suite 1030 

Milwaukee, WI 53202 
(414) 225-9755 

Attorney Docket No.: 1 506.022 


{00102566.DOC /} 


